This pull request makes use of the new tailwindcss@4 API, and a new CSS parser called css-tree. It makes the code much simpler (since Tailwind now exposes a function to generate styles), much smaller (since we only need to bundle css-tree for a distribution issue csstree/csstree#352) and it gets slightly faster than the previous version.

The pull request also introduces a few changes to the changes we made for email compatibility to work well with the new CSS features used in tailwindcss@4.

Currently available on npm through @react-email/[email protected]

Compatibility

tailwindcss@4 introduces the use of some new CSS features in certain ways that email clients don't support, here's a list of them and the respective way of how we change the genreate CSS to have better email client support.

• Uses oklch as the default color function, which is almost not supported at all: we convert it, and most other colors to rgb(red,green,blue,alpha) syntax
• Uses calc expressions extensively (e.g. m-* utiltiies): we evaluate simple calc expressions which should be enough for the vast majority of the utilites that have
• Uses border-radius:calc(Infinity*1px) instead of 9999px for rounded-full: Convert to using 9999px instead directly

There might still be some other compatibility issues that we can't see, and some ones that I suspect might not be supported so we still need to test it on Litmus before releasing a stable version.

Performance

After the initial changes to actually get tests working, I noticed performance issues, where just email rendering would get into a few a seconds for not such a complicated email template. One of the reasons was code introduced in this pull request to deal with compatibility issues, but it was mainly because of repeated parse calls to css-tree. I knew this was the case after profiling with Node.js's profiling and the flamegraphs in https://discoveryjs.github.io/cpupro.

Before tailwindcss@4, we were using using postcss which was the same CSS parser that was used for tailwindcss@3 so it made integration much simpler. Now, with tailwindcss@4 they're using their own seemingly proprietary minimal CSS parser that is not exposed, meaning we need to pick one ourselves. With that new parser, we end up also repeatedly parsing the CSS coming from tailwind instead of reusing what already has parsed under the hood.

To actually get reasonable performance running with tailwindcss@v4, by avoiding repeatedly parsing the CSS returned from the build function coming from tailwindcss, this pull request also introduces a new way of inlining styles for components.

Before this pull request, we would always inline styles for components and elements alike. But, for components we did not strip away the original classes that were associated with the inlined styles. Now, we only inline styles for elements, and not for any component, unless the component has a tailwindTreatAsElement = true property to it, which we do for some components now (e.g., Button).

This is actually a much more intuitive user experience than what we had before since it brings it closer to what users would already be used to when using tailwindcss.